home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 1 / QRZ Ham Radio Callsign Database - December 1993.iso / ucsd / packet / tcpip / sys5 / iscwmpst.z / iscwmpst / tcp / src / onotes < prev    next >
Encoding:
Text File  |  1991-06-22  |  23.0 KB  |  561 lines
  1. $ $ ===============================================================================
  2.  
  3. > Hm ich wuerde sie auch nicht verstehen. War wohl ein bissl im Tran vorhin.
  4. > Ich meinte, dass ich meine Sessions auf die Funktionstasten gelegt hatte,
  5. > d.h. mit f1 die erste, f2 die zweite etc., einfach aus der Faulheit
  6. > heraus, <esc> und dann 'sess x' einzugeben. Auf F10 habe ich mir den
  7. > Status-Befehl gelegt. Meine Frage war, ob's auch bei den HP-Terminals
  8. > Funktionstasten gibt, und ob die Ansi-Sequenzen da irgendwie genormt sind.
  9. > Bei mir ist f1 z.B. ^[OP, f2 ^[OQ usw.  Wenn die Terminals da kompatibel
  10. > waeren, koennte man damit auch das esc-Problem erschlagen, da dann der
  11. > Druck einer F-Taste zum Wechseln der Session bzw. zum Wechseln in den
  12. > Commandmode fuehren wuerde.
  13. > Hoffentlich war das jetzt verstaendlich, werde nun erstmal ins Bett gehen,
  14. > sonst kommt eh nichts mehr raus.
  15. > 73s,
  16. > noch einen schoenen Abend
  17. > Olaf
  18.  
  19. Jetzt habe ich Dich  verstanden.  Die Codes fuer HP  Terminals  und ANSI
  20. Terminals sind zwar verschieden, aber das eigentliche  Problem ist, dass
  21. der  momentane  ttydriver  so lange  Sequenzen  nicht  dekodieren  kann.
  22. Bisher versteht er nur
  23.  
  24.   ESC   [   <char>
  25.         ^
  26.         |
  27.      optional
  28.  
  29. Langfristig  koennte man das schon einbauen, aber momentan  drueckt mich
  30. das CRC Problem mehr.
  31.  
  32. ===============================================================================
  33.  
  34. - CHECK:        overflow in mail buffers
  35.  
  36. - IMPLEMENT:    ax25 blimit
  37.  
  38. - IMPLEMENT:    netrom blimit
  39.  
  40. - ping (record route) does not work
  41.  
  42. - brauchen die Broadcast Addressen noch das E-Bit?
  43.  
  44. ===============================================================================
  45.  
  46.     &TCB Rcv-Q Snd-Q  Local socket           Remote socket          State
  47.    62880     0  1017  dk5sg:ftp-data         dc3sn:1008             Closed
  48.  
  49. Local: dk5sg:ftp-data Remote: dc3sn:1008 State: Closed
  50.       Init seq    Unack     Next Resent CWind Thrsh  Wind  MSS Queue      Total
  51. Send: 3c580000 3c58e809 3c58e9ba  11233   432   216  1080  216  1017      59401
  52. Recv: 7538eff0          7538eff1      0              1080          0          1
  53. Backoff 11 Retrying Timer stopped SRTT 12130 ms Mean dev 7213 ms
  54.  
  55. ===============================================================================
  56.  
  57. - richtige Verwendung von Mycall pruefen
  58.  
  59. - "will echo" implementieren und testen (all telnet options)
  60.  
  61. - ax25 rtt cache?
  62.  
  63. - netrom rtt cache?
  64.  
  65. - rip request testen
  66.  
  67. - remote_kbd: stop tracing to stdout
  68.  
  69. - tty.h; ttydriv an session koppeln (Schwierigkeit: keine CmdSession)
  70.  
  71. - ttylink?
  72.  
  73. - trace for netrom selfconnects
  74.  
  75. - don't switch STREAM -> DGRAM after connection
  76.  
  77. - hosttable stuff ==> domain.c
  78.  
  79. - wo soll retry = 0 gesetzt werden ?
  80.  
  81. - AX.25:  VC Mode fuer IP einbauen
  82.  
  83. - AX.25:  axserver auch in die Liste haengen?
  84.  
  85. - AX.25:  gibt es mehrere strtopath ?
  86.  
  87. - Netrom:  Knoten sollen durch Ident ansprechbar sein
  88.  
  89. - Netrom:  print_destname ueberall verwenden
  90.  
  91. - Netrom:  den Ident wie eine AX25 Adresse behandeln
  92.  
  93. - Netrom:  struct circuit doppelt verpointern
  94.  
  95. - Netrom:  TTL default auf 25 erhoehen ?
  96.  
  97. - Mailer:  Alle Message Delimiter entfernen
  98.  
  99. - Mailer:  Use hierarchical addressing
  100.  
  101. - Mailer:  Use 'host-mode'
  102.  
  103. ===============================================================================
  104.  
  105. From dl5ue Wed Mar 22 14:44 MEZ 1989
  106. Received: by db0sao; Wed, 22 Mar 89 14:44:33 mez
  107. Date: Wed, 22 Mar 89 14:44:33 mez
  108. From: Jan Schiefer <dl5ue>
  109. Return-Path: <dl5ue>
  110. To: dk5sg
  111. Subject: netrom.c
  112. Status: R
  113.  
  114. Hallo Dieter,
  115.  
  116. leider bin ich erst heute dazu gekommen, mir netrom.c in Ruhe anzusehen. Am
  117. Montag war mir aufgefallen, dass von den WAMPI sehr haeufig gebroadcastet
  118. wurde. Heute trat das Problem scheinbar nicht auf, hast Du was geaendert?
  119.  
  120. Beim Lesen Deines Codes sind mir einige Dinge aufgefallen: In calculate_
  121. routes ziehst Du den Broacast-Timer auf 10s auf. Ich finde, man sollte da
  122. unbedingt eine Zufallszahl in der Groessenordnung 0...60s dazuaddieren, da
  123. sonst folgendes passieren koennte:
  124. A broadcastet Aenderungen, B und C hoeren dies, bei beiden ergeben sich
  125. auch Aenderungen. Sie starten ihre Broadcast-Timer und broadcasten zwar
  126. ohne Kollision, aber doch fast gleichzeitig. Da ist die Chance sehr gut,
  127. dass der Bs BC im TNC wartet, bis Cs BC vorbei ist. Anschliessend BCed B
  128. veraltete Routen, was wiederum A und C hoeren....usw.
  129.  
  130. Ausserdem fiel mir auf, dass auch bei einem BC 'ausser der Reihe' immer
  131. alle Routen gebroadcasted werden. Was haeltst Du davon, bei solchen BCs
  132. nur neighbor und quality derjenigen Destinations zu senden, bei  denen
  133. force_broadcast != 0 ist? Dadurch wuerde das Datenvolumen auf dem Kanal
  134. kleiner, ausserdem koennten mitlesende Spanner leichter beobachten, ob es
  135. Probleme bzw. Schwingungszustaende gibt. (Dann allerdings sollte man die
  136. normalen BCs grundsaetzlich immer machen, wenn der obsolesence_timer aus-
  137. laeuft, da sonst bei anderen Stationen der obs-counter u.U. veraltet, wenn
  138. laenger als 1/2 h kein vollstaendiger BC kommt).
  139.  
  140. Das was eigentlich das, was mir ins Auge stach. Ach ja, nochwas: So schwer
  141. ist das ja eigentlich gar nicht zu lesen + verstehen....
  142.  
  143. Gibt's was Neues von Deinem 70er Funk?
  144.  
  145. Bis bald,
  146. Jan
  147.  
  148. ===============================================================================
  149.  
  150. bbs mailer:
  151.  
  152. - wenn ich eine SID bekomme antworte ich mit meiner SID
  153.  
  154. - nach dem S Kommando wird auf OK/NO gewartet
  155.  
  156. - bei OK wird die Msg gesendet
  157.  
  158. - bei NO wird die Msg dem return_mailer uebergeben
  159.  
  160. - ich sende wenn moeglich hierachical adresses
  161.  
  162. ===============================================================================
  163.  
  164. HP:
  165. ---
  166.  
  167. ftp> put /hp-ux /tmp/x
  168. 200 PORT command okay.
  169. 150 Opening data connection for /tmp/x (127.0.0.1,1103).
  170. 226 Transfer complete.
  171. 802432 bytes sent in 6.72 seconds (116.58 Kbytes/sec)
  172.  
  173. ftp>
  174.  
  175. WAMPES:
  176. -------
  177.  
  178. put /users/funk/dk5sg/p.Z
  179. 200 Port command okay
  180. 150 Opening data connection for STOR /users/funk/dk5sg/p.Z
  181. Put complete, 3638 bytes sent
  182. 226 File received OK
  183.  
  184. ===============================================================================
  185.  
  186. S DC3SN    < DK7WJ
  187. OK, go ahead
  188. SEARCH U. WAMPES
  189. R:160289/1113  @DB0GV  [RMPRG Maintal-Frankfurt JO40KD OP: DF5FF (438.025 MHz)]
  190. de DK7WJ @ DB0GV
  191.  
  192. hallo Thomas, du hast den Finger auf der Wunde hi
  193. Ich hab die Sache bereits mit DB0IE ausprobiert, wo Wampes ja seit einiger
  194. Zeit auch laeuft. Der Suchframe (UI mit Poll) wird von Wampes normal
  195. digipeated, dummerweise aber nicht der Antwort-DM. Der wird von Wampes
  196. verschluckt, weil es vermutlich alle Frames ausser UI nur in dem High-
  197. Level-Pseudodigi (schoenes Wort) verarbeitet und dort feststellt, dass
  198. der DM zu keinem laufenden QSO gehoert. Also wird er verworfen.
  199. Bei Flexnet ist das so gemacht, dass alle Frames, die nicht zu einem QSO
  200. gehoeren, normal digipeated werden, was auch den Vorteil hat, dass bei
  201. vollen QSO-Tabellen oder nach einem Restart des Knotens die QSOs per
  202. L2-Digipeating weiterlaufen. Dadurch kommen auch die DMs durch. Diese
  203. Loesung bringt natuerlich auch noch weitere Schwierigkeiten, so muessen
  204. z.B. alle QSOs nach dem Disc noch ein paar Minuten weiter gefuehrt werden,
  205. damit die Trennung auch bei DISC-Retries noch funktioniert. Dies ist auch
  206. so gemacht, sie tauchen nur nicht mehr in der Userliste auf. Weiterer Vorteil:
  207. Noch vorhandene I-Frames bleiben fuer einen eventuellen Reconnect noch ne
  208. Weile gespeichert, leider fuehrt das manchmal zu doppelten Ctexten, aber das
  209. ist m.E. das kleinere Uebel.
  210. Der Suchframe ist ueberigens so aufgebaut, dass er garnicht zu einem laufenden
  211. QSO passen kann, der absendende Digi guckt naemlich erst in seiner QSO-Liste
  212. nach, ob der Gesuchte schon mit ihm connected ist. Wenn ja, wird sofort die
  213. "gefunden"-Msg gesendet.
  214. Waere fein, wenn Dieter die Sache bei Wampes umbauen koennte, ev. gleich
  215. mit Integration des Suchframes. Dieser sieht uebrigens wie folgt aus:
  216. <Absenderdigi> -> <Gesuchter> via <Suchender> <Absenderdigi>* [Digis] UI cp
  217. Leider ist im Moment der Link DA<->ID sehr schlecht, weshalb solche Frames
  218. leider oft verlorengehen... Wenn diese Msg nicht ausreicht, kann ich aber
  219. trotzdem gerne mal nen Suchpfad bei ODW einbauen, pse kurze msg!
  220. 73 Gunter   DK7WJ @ DB0GV
  221.  
  222. ===============================================================================
  223.  
  224. Hallo Jan, ich denk mir eben dass ich euch die Konzeptbaustelle schon mal
  225. zuschicke, dann koennt ihr parallel daran arbeiten und Fehler suchen helfen.
  226. Zum Codieren komm ich eh erst in 2-3 Wochen, vorher gibts fuer den RMNC noch
  227. nen Update mit einigen Features mehr und einigen Bugs weniger, die Version
  228. mit Router will ich so ca. zur Ham Radio fertig haben... kann sein dass in
  229. dem folgenden Papier noch Fehler drinstecken, ist wie gesagt nur der Entwurf
  230. fuer das Skript, also pse Nachsicht... so los gehts:
  231.  
  232.                     Features FlexNet Sink-Tree-Router      Stand: 20.04.89
  233.                     =================================
  234.  
  235. -   Netzknoten unterhalten untereinander staendig eine L2-Verbindung fuer
  236.     Routing Updates und zur Kontrolle des Links
  237. -   Nach (Wieder-)anlauf eines Knotens hat dieser keinerlei Informationen ueber
  238.     die Netztopografie, die Kenntnis seiner Nachbarn ausgenommen. Also meldet
  239.     der Knotes diese Tatsache seinen Nachbarn, worauf diese ihm sofort alle
  240.     ihnen bekannten Nodes zuspielen, diese Info enthaelt einen Parameter fuer
  241.     die Route-Qualitaet, die analog zur Netrom-Loesung ermittelt wird.
  242. -   Unser Knoten hat nach dieser ersten Lernphase eventuell mehrere Routes zu
  243.     einem Ziel erhalten, er speichert die 3 besten und benutzt hinfort den
  244.     besten.
  245. -   Diese Liste wird nun durchgesehen, unser neunmalkluger Knoten hat nun
  246.     sicherlich fuer manche Ziele viel bessere Pfade gelernt, als er sie von
  247.     einem seiner Nachbarn gemeldet bekam. Sicher gilt das z.B. fuer die jeweils
  248.     anderen Nachbarn, zu denen er ja bereits eine Verbindung unterhaelt.
  249.     Jetzt wird es aber kritisch: Meldet er diese besseren Pfade einfach weiter,
  250.     kann es passieren, dass nach einem Ausfall dieser momentan noch besseren
  251.     Strecken eine Loop entsteht, denn er wuerde ja dann sofort den zweitbesten
  252.     Weg waehlen, der dann aber leider genau der Rueckweg ist. Um dieses Problem
  253.     zu loesen, greifen wir zu einem Algorithmus, der in der Literatur als "Sink
  254.     Tree" bekannt ist.
  255.  
  256.     Bezogen auf ein bestimmtes Ziel steht jeder Knoten an einer Gabelung eines
  257.     Baumes. Er muss stets informiert sein, wo in diesem Baum die Nachbarn
  258.     angeordnet sind, d.h. ob sie auf dem Weg zum Ziel liegen oder ob umgekehrt
  259.     diese ihre Packets fuer den Zielknoten ueber uns routen. Er darf NIEMALS
  260.     Packets in der Gegenrichtung routen, also zu einem Knoten, der von ihm aus
  261.     weiter hinten liegt. Wenn wir nun den Ausfall unserer Strecke bemerken und
  262.     auch keine Alternative im obigen Sinne finden, senden wir einen Hilferuf an
  263.     die Knoten unter uns: "Ich kann Knoten x nicht mehr erreichen!" Wenn der
  264.     Knoten darunter eine Alternative hat, sendet er diese Information zurueck,
  265.     der Fall ist erledigt, fuer dieses Ziel haben die beiden Knoten ihre
  266.     Position auf dem Baum getauscht. Wenn unser Nachbar auch keine Alternative
  267.     kennt, sendet er diesen Hilferuf ueber alle Links weiter. Dies setzt sich
  268.     fort, bis irgendwo im Netz ein Knoten einen alternativen Weg kennt. Diese
  269.     wird dann normal bekanngemacht, wobei die Knoten ihren neuen Platz auf dem
  270.     Baum einnehmen. Die Hilferufe fuehren natuerlich bei jedem Knoten dazu, dass
  271.     die entsprechende Routinginformation geloescht wird. Wohlgemerkt: Dieser
  272.     Baum existiert fuer jedes im Netz bekannte Ziel, Die Implementierung der
  273.     Nodestabelle ist recht einfach: Fuer jeden Nachbarn wird eine Spalte
  274.     eingerichtet, in der die Streckenqualitaeten zum jeweiligen Zielknoten
  275.     stehen. Ein Nachbar, der ueber uns routet, wird mit der Qualitaet 0
  276.     versehen. Wenn wir einem Nachbarn eine Linkinfo senden, gehen wir immer erst
  277.     davon aus, dass dieser den Weg ueber uns auch benutzen darf. Sofern er uns
  278.     eine Strecke meldet, wird er niemals ueber uns routen, und wir koennen
  279.     diesen Weg verwenden.
  280.  
  281.     Wenn wir keinen verwertbaren Weg zu einem Ziel mehr haben, senden wir auf
  282.     allen Links einen Hilferuf aus, der besagt, dass wir keinen Weg zum
  283.     Zielknoten mehr kennen. Die Nachbarn loeschen draufhin den Weg ueber uns und
  284.     schauen dann nach, ob sie eine Alternative haben: Wenn ja, teilen sie sie
  285.     uns mit, wenn nein, senden sie den Hilferuf weiter. Dies setzt sich fort,
  286.     biss alle Knoten den Ruf erhalten haben und keiner einen Pfad zum Ziel
  287.     kennt. Gibt es jedoch einen solchen, dann wird diese Information wie beim
  288.     Kaltstart verbreitet. Die Routinginformationen fuer diesen Zielknoten bauen
  289.     sich dann neu auf, sobald irgendwo ein Weg bekannt ist. Wenn ein Knoten
  290.     nicht mehr erreichbar ist, wird er auf diesem Wege aus allen Knoten
  291.     ausgetragen.
  292.  
  293. --------------
  294.                     Datenstruktur Routing Table
  295.                     ===========================
  296.  
  297. Fuer jede gemeldete Node ein Eintrag, ausser fuer die Nachbarn, diese
  298. stehen samt Kanalnummer in einer eigenen Liste (Nachbarliste)
  299.  
  300. <CALL(7)> <3*[<Nachbar-Nummer>,<Qualitaet>]> <Upstr Flags> <Updt Flags>
  301.  
  302. Nachbar-Nummer: Index in Nachbarliste
  303. Qualitaet: Link-Qualitaet, Berechnung wie NET/ROM
  304. Upstr-Bitflags: Fuer jeden Nachbarn ein Bit als Kennung: Nachbar ist Upstream
  305. Updt-Bitflags: Fuer jeden Nachbarn ein Bit als Kennung: Update Info senden
  306.  
  307. Summe: 21 Bytes/Node bei max. 32 Nachbarn
  308.  
  309.            Verwaltung der Routing Table (Pseudocode)
  310.            =========================================
  311.  
  312. Kaltstart:
  313.     {
  314.     Routing Table loeschen
  315.     Hauptschleife:
  316.         {
  317.         Alle ca. 5 Minuten:
  318.             {
  319.             L2-QSO zu L3-Nachbarn initiieren, falls nicht connected
  320.             ((( Nachbarn identifizieren, Versionen abgleichen )))
  321.             }
  322.  
  323.         Neues L2-QSO mit bekanntem Nachbar:
  324.             {
  325.             In allen Routes Update-Flags fuer diesen Nachbarn setzen
  326.                 und Upstream-Flags loeschen
  327.             }
  328.  
  329.         L2-QSO zu Nachbar zusammengebrochen:
  330.             {
  331.             Alle Flags (Update und Upstream) fuer diesen Nachbarn loeschen
  332.             Route-Qualitaeten via diesem Nachbarn loeschen, wenn dadurch
  333.                 zu Zielen der beste Weg verlorengeht, Update-Flags fuer alle
  334.                 Upstream-Nachbarn fuer dieses Ziel setzen, d.h. Update-Bits
  335.                 von Upstream kopieren
  336.             }
  337.  
  338.         periodisch (z.B. alle 100ms eine Route oder alle 10s alles)
  339.             {
  340.             Plaetze ohne verwendbaren Weg loschen, falls kein Update-
  341.             Flags gesetzt
  342.  
  343.             Eine Route auf gesetzte Update-Flaggen testen:
  344.                 {
  345.                 Routing Info senden, wenn gelungen, Update loschen und
  346.                     Upstream setzen, sofern gemeldete Qualitaet > 0
  347.                 Eventuelle Route-Qualitaet via diesem Nachbarn auf 0 setzen!!
  348.                 }
  349.             }
  350.  
  351.         Route-Info erhalten?
  352.             {
  353.             Neue Node && Qualitaet > 0 (kein Hilferuf)?
  354.                 {
  355.                 Tabellenplatz fuer Node einrichten, alles auf 0 setzen
  356.                 }
  357.  
  358.             Qus
  359. alitaet > 0?
  360.                 {
  361.                 Upstream-Flag f. Nachbar loeschen
  362.                 }
  363.  
  364.             Gemeldete Qualitaet <= den bekannten?
  365.                 {
  366.                 Wenn dieser Nachbar besser ueber uns ginge, da sich fuer ihn
  367.                 ein besserer Weg ergibt als gemeldet, Update Flag setzen!
  368.                 }
  369.  
  370.             Bereits 3 Routes gespeichert?
  371.                 {
  372.                 Schlechteste Route loeschen und neue Route eintragen, falls
  373.                 nicht die schlechteste
  374.                 }
  375.  
  376.             Beste Qualitaet besser geworden (auch wenn neue Node!)
  377.                 {
  378.                 Fuer alle Nachbarn mit eingetragenen Qualitaeten berechnen,
  379.                 ob sie ueber uns besseren Weg haetten, wenn ja->Update-Flag
  380.                 }
  381.  
  382.             Durch Meldung beste Qualitaet schlechter geworden?
  383.                 {
  384.                 Fuer alle Nachbarn OHNE eingetragene Qualitaet Update-Flag
  385.                 ausser fuer den meldenden Nachbarn
  386.                 }
  387.             }
  388.  
  389.                     Syntax Routing Updates
  390.                     ======================
  391.  
  392.     --- noch zu definieren (moeglichst eigene PID)
  393.  
  394.                     Link-Qualitaeten
  395.                     ================
  396.  
  397. Aufgrund dews Sink-Tree-Algorithmus ist es unabdingbar, dass eine Strecke
  398. auf beiden Seiten die gleiche Qualitaet besitzt. Alternativ koennte man
  399. in der Setup-Phase eines QSOs zwischen Nachbarn die eigene Qualitaet
  400. uebertragen. Ein automatisches Update der Qualitaet in Abhaenigkeit der
  401. Belegung erscheint nicht sinnvoll, da dies zu zuvielen Updates im Netz
  402. fuehren kann. Folgende Qualitaeten werden beim RMNC voreingestellt
  403. (Aenderung durch Sysops nicht vorgesehen):
  404.  
  405.           Baudrate   Vollduplex  Halbduplex
  406.  
  407.             9600        252         249
  408.             4800        249         243
  409.             2400        243         232
  410.             1200        232         211
  411.              600        211         175
  412.              300        175         120
  413.  
  414. Die Berechnung einer Route-Qualitaet geschieht wie bei NET/ROM:
  415.                 Rc' = (Cc * Rc + 128)/256
  416.  
  417. Rc': Neue Routequalitaet; Rc: Alte Routequalitaet; Cc: Kanalqualitaet
  418.  
  419.                     Routing-Algorithmus
  420.                     ===================
  421.  
  422. Konzept:
  423.    Virtual Circuit Router unter Verwendung des AX25-Adressfeldes
  424.  
  425. Wird bei FlexNet-QSOs nur bei SABM und UI durchlaufen, ausserdem bei
  426. Frames, die nicht zu einem laufenden QSO passen.
  427. Routing uebertragbar auf Digis ohne Hop-to-Hop-Ack
  428.  
  429. Wir sind nicht naechster Digi?
  430.     {
  431.     verwerfen!
  432.     }
  433.  
  434. Wenn auf exclusivem Linkkanal empfangen: Letztes Call als Nachbar
  435.   bekannt?
  436.     {
  437.     verwerfen!
  438.     }
  439.  
  440. Letztes Call als Nachbar bekannt && nicht 1. Digi && vorletztes Call als
  441.   Node bekannt?
  442.     {
  443.     Letztes Call aus Callfeld loeschen, folgende Calls aufruecken
  444.     }
  445.  
  446. Naechstes Call als Node bekannt && Route vorhanden?
  447.     {
  448.     Call des Nachbarn, ueber den gerouted wird, nach unserem einschieben
  449.     }
  450.  
  451. Jetzt routen nach V2-Methode, also entsprechend SSID oder Nachbarn
  452.  
  453. H-Bit und ev. SSID fuer unser Call setzen
  454.  
  455. Frame senden (Bei FlexNet-SABM QSO-Allokierung)
  456. }
  457.  
  458.                 Vorteile von FlexNet Virtual Circuit
  459.                 ====================================
  460.  
  461. - Keine Fragmentierung von langen I-Frames durch Network Header Overhead
  462. - Das vorhandene Digipeaterfeld im AX.25-Protokoll wird sinnvoll weiter-
  463.   verwendet
  464. - Jede monitorende Station sieht sofort, wer mit wem ueber welche Strecke
  465.   arbeitet, Up- und Downlink sind symmetrisch, d.h. man kann die anrufende
  466.   Station ueber den gemeldeten Pfad zurueckconnecten
  467. - Deutlich groesserer Durchsatz durch:
  468.     a) Entfall des Rechenaufwandes durch Routing jedes einzelnen I-Frames
  469.     b) Kein festes End-to-End-Window, das Window ergibt sich durch die
  470.        Summe der eingestellten MAXFRAMES der auf der Strecke liegenden
  471.        Knoten
  472.     c) Fuer jedes QSO individuelles Flow-Control moeglich, dadurch optimale
  473.        Auslastung von schnellen Teilstrecken; ueberlastete, weil z.B. lang-
  474.        same Teilstrecken bremsen nur noch die QSOs, die ueber diese Strecken
  475.        laufen muessen
  476.  
  477. - Durch die Transparenz Unprotos und andere Protokollvarianten moeglich, z.B.
  478.   Netrom-Vekehr ueber FlexNet-Teilnetze mit 2 anzugebenden Digis
  479. - Keinerlei Einschraenkungen bezueglich PIDs
  480. - Einstufiger Verbindungsaufbau mittels Angabe von Einstiegs- und Ausstiegs-
  481.   knoten
  482. - Endstellen, die als Nachbarn definiert sind (z.B. Mailboxen), koennen
  483.   von entfernten Knoten ohne Angabe des letzten Digis connected werden,
  484.   z.B. "C DB0CZ via DB0ODW"
  485. - Wenn beim Verbindungsaufbau bei einem Knoten auf der Strecke kein RAM frei
  486.   ist, wird QSO nach gleichem Routingverfahren auf dieser Teilstrecke per
  487.   L2-Digipeating ausgefuehrt, dadurch kein hartes Limit der QSO-Anzahl
  488. - Sehr einfache Implementierung, zumindest bei FlexNet und, wenn ohne Hop-
  489.   to-Hop-Acknowledge realisiert, auch bei anderen Knotenrechnerkonzepten
  490. - Durch Entfall des speziellen L4 kuerzerer Code
  491.  
  492.             Nachteile gegenueber Datagram-Routing (z.B. NET/ROM)
  493.             ====================================================
  494.  
  495. - Jedes QSO, das ueber einen Netzknoten abgewickelt wird, belegt Speicher-
  496.   platz, sofern es per Hop-to-Hop-Ack abgewickelt wird (bei FlexNet ca.
  497.   200 Bytes + zwischengespeicherte Frames)
  498. - Dynamisches Umrouten bei WAEHREND eines QSOs ausgefallenen Knoten und
  499.   Strecken nicht moeglich, Verbindung muss neu aufgebaut werden
  500.    (Riesennachteil!! Relativiert durch durchschnittliche QSO-Dauer, zuver-
  501.     laessiges Netz, Zusammenbruch ergibt aussagekraeftige Fehlermeldung des
  502.     Knotens, der die Verbindung nicht weiterfuehren konnte)
  503. - Es koennen mehr als 8 Digis im Rufzeichenfeld entstehen, dieser Fall muss
  504.   entsprechend behandelt werden, entweder zurch Zulassen von 10 Digis oder
  505.   durch Verwerfen dieser Frames
  506.  
  507.                        Auswirkungen fuer User
  508.                        ======================
  509.  
  510. - User brauchen sich nicht umzustellen, es kann nach wie vor der komplette
  511.   Pfad angegeben werden
  512. - User kann am Einstiegsdigi die Nodesliste abrufen, wenn sein Ausstiegsdigi
  513.   in der Liste steht, kann er die dazwischenliegenden Digis weglassen
  514. - Nach wie vor einstufiger Verbindungsaufbau ueber das bekannte Netzwerk
  515. - Uebergang erfolgt gleitend, Vorteile entstehen sobald min. 3 Digis in
  516.   Reihe dieses Verfahren beherrschen (mittlerer Digi kann weggelassen werden)
  517.  
  518.                   Allgemeine Argumente gegen NET/ROM
  519.                   ==================================
  520.  
  521. 1. Router (L3)
  522.   - Ein Netzknoten besteht in Wirklichkeit aus mehreren "Nodes", die man
  523.     zwar verstecken kann, aber sie existieren und belasten die Routing-
  524.     tabellen
  525.   - NET/ROM hat Schwierigkeiten mit Loops, die beim Ausfall von Linkstrecken
  526.     oder Netzknoten entstehen koennen
  527.   - Ausgefallene Nodes werden zu langsam bekanntgemacht, Erhoehen der Update-
  528.     rate belastet Netz zu stark, zumindest bei 1200 Baud-Links
  529.   - Durch Sendung der Routinginfo als Broadcast geringe Uebertragungssicher-
  530.     heit, u.a. deshalb periodische Wiederholung noetig
  531.   - Konzipiert fuer ein sehr dynamisches Netz mit vielen Linkpartnern auf
  532.     einer Frequenz, daraus resultieren z.T. obige Maengel.
  533.   - Prinzipbedingt (Datagram Routing) Probleme mit Flow Control, dadurch
  534.     u.U. schlechte Frequenzauslastung
  535.  
  536. 2. Transport (L4)
  537.   - Trennen der Verbindung nach ~10 Minuten ohne Aktivitaet, waere behebbar
  538.     durch "L4V2" mit Command/Poll
  539.  
  540. 3. Up-Downlink
  541.   - Beim Monitoren ist der Pfad nicht ersichtlich
  542.   - Zwecks Rueckruf muss der Einstiegsdigi des Partners bekannt sein
  543.   - SSID-Drehung, dadurch eingeschraenkte Verwendbarkeit von SSIDs und
  544.     moegliche Irrtuemer beim Zurueckconnecten
  545.   - Verbindungsaufbau uebers Netzwerk generell dreistufig, dadurch kein
  546.     automatischer Verbindungsaufbau mit normalen Terminalprogrammen durch
  547.     Funktionstastenbelegung moeglich
  548.   - "Weiterconnecten" fuehr bei vielen QSOs zu Zickzackroutes mit unnoetiger
  549.     Netzbelastung
  550.   - Digi sendet nicht unter seinem Rufzeichen, dadurch z.B. Irrtuemer bei
  551.     Feldstaerkeermittlung
  552.  
  553. Sodele, oje, ist doch schon etwas laenglich fuer diese Betriebsart hi
  554. also, bei Bedarf werd ich die Updates auch wieder rueberspielen, hab aber
  555. wie gesagt in den naechsten Tagen sehr wenig Zeit fuer den Kram
  556. 73 Gunter
  557.  
  558. ===============================================================================
  559.  
  560. $ ksh: s:  not found
  561. $